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Abstract. In this paper, we present a method and a tool to build sym- 
bolic labelled transition systems from B specifications. The tool, called 
GeneSyst, can take into account refinement levels and can visualize the 
decomposition of abstract states in concrete hierarchical states. The re- 
sulting symbolic transition system represents all the behaviors of the 
initial B event system. So, it can be used to reason about them. We il- 
lustrate the use of GeneSyst to check security properties on a model of 
electronic purse. 



1 Introduction 

Formal methods, such as the B method [1], ensure that the development of an 
application is reliable and that properties expressed in the model are satisfied by 
the final program. However, they do not guarantee that this program fulfills the 
informal requirements, nor the needs of the customer. So, it is useful to propose 
several views about the specifications, in order to be sure that the initial model 
is suitable for the customer and that the development can continue on this basis. 
One of these important insights is the representation of the behavior of programs 
by means of diagrams (statecharts). Moreover, some particular views, if they are 
themselves formal, can provide new means to prove properties that cannot easily 
be checked in the first model. 

In this paper, we present a method and a tool to extract a labelled transition 
system from a model written in event- B. The transition system gives a graphical 
view and represents symbolically all the behaviors of the B model. The method 
is able to take into account refinement levels and to show the correspondence 
between abstract and concrete systems, by means of hierarchical states. 

We present also an application of this tool, namely, the verification of secu- 
rity properties. The security properties assert the occurrence or the absence of 
some particular events in some situation. They are a case of atomicity property 
of transactions. This is illustrated by an example of specification of an elec- 
tronic purse, called Demoney[16, 15], developed in the SecSafe project [19]. This 
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case study, written in Java Card [21], is an applet that has all the facilities 
required by a real electronic purse. Indeed, the purse can be debited from a 
terminal in a shop, credited by cash or from a bank account with a terminal in 
a bank or managed from special terminal in bank restricted area. Transactions 
are encrypted if needed and different levels of security are used depending on 
the actions. Demoney also supports to communicate with another applet on the 
card, for example, to manage award points on a loyalty plan. The specification 
of Demoney is public in version 0.8 [16], but the source code is copyrighted by 
Trusted Logic S.A. 1 . 

In Section 2, we recall the main features of event- B systems and refinements. 
We introduce a notion of behavioral semantics by the way of sequences of events. 
In Section 3, we define symbolic labelled transition systems (SLTS) and the 
links between SLTS and event-B systems are stated. In Section 4, we present 
the GeneSyst tool and an example of generation of SLTS dealing with the error 
cases in the Demoney case study. Section 5 presents security properties required 
in the application and shows how the GeneSyst diagrams can be used to check 
these properties. Then, we review related works, and we conclude the paper with 
some research perspectives in Section 6. 

2 Event-B 

2.1 General presentation 

Event-B was introduced by J.-R. Abrial [2, 3]. It is a formal development method 
as well as a specification language. In event-B, components are composed of con- 
stant declarations (sets, constants, properties), state specification (vari- 
ables, invariant), initialisation and set of events. The events are defined by 
e = eBody where e is the name of the event and eBody is a guarded generalized 
substitution [1]. The events do not take parameters and do not return result 
values. They do not get preconditions and do terminate. Their effect is only to 
modify the internal state. If S is a component, then we denote by Interface(S) 
the set of its events. 

A well-typed and well-defined component is consistent if initialization Init 
establishes the invariant of the component and if each event preserves the invari- 
ant. So, using the notation [S]R as the weakest precondition of R for substitution 
S, the consistency of a component is expressed by the proof obligations: [Init] I 
and / => [eBody]! for each event. 

In the paper, we use the notions of before-after predicate of substitution 
T for variables x (prd x (T)) and the feasability predicate of a substitution as 
defined in the B-Book: fis(T) ^ -i[T]false [1]. Finally, the notation (T)R means 
-i[T]-ii?, that is to say, there exists a computation of T which terminates in a 
state verifying R. 
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2.2 Events and traces 



The events have the form "e = G => T" where G is a predicate, T is a 
generalized substitution such that I A G => fis(T). Predicate G is called the 
guard of e and T is its action. They are respectively denoted by Guard(e) and 
Action{e). If the syntactic definition of an event e = S does not fulfill this 
form, it can be built by computing e = fis(5) => 5. Following the so-called 
event-based approach [10], the semantics of event- B systems can be chosen to be 
the set of all the valid sequences of event executions. 

Definition 1 (Traces of Event- B systems) A finite sequence of event occur- 
rences eo.e1.e2 . . . e n is a trace of system S if and only if eo is the initialisation 
of S, {ei, e2, ■ • ■ , e„} C Interface(S) and fis(eo ; e\ ; e2 ; ... ; e„) ^ true. 

The set of all the finite traces of a system S is called Traces (S). For the initial- 
isation, one can notice that prd x (imf) does not depend on the initial values of 
the variables and that Guard(Init) <^> true. The following property characterizes 
traces by the existence of intermediary states Xi in which the guard of a holds 
and where the pair (xi, Xi + \) is in the before-after predicate of event e^: 

Property 1 (Trace characterization) Let x be the variable space of system 

S, then: eo.ei e„ <E Traces(S) 

3xo,...,x n+ i • ALo([ x : = Xi]Guard(ei) A [x,x' := Xi,x i+1 }prd x (Action(ei))) 

2.3 Event- B refinement 

In the event-B method, a refinement is a component called refinement. The 
variables can be refined (i.e. made more concrete) and a gluing invariant de- 
scribes the relationship between the variables of the refinement and those of the 
abstraction. The events of refinement TZ must at least contain those of the ab- 
straction S (i.e. Interface(S) C Interface(lZ)). The other events are called new 
events. 

We recall here the proof obligations of system refinements. Let / be the invari- 
ant of the abstraction S and J be the invariant of refinement TZ, then the gluing 
invariant is the conjunction I A J. The refinement is performed elementwise, that 
is to say, the abstract initialisation is refined by the concrete initialisation and 
each abstract event is refined by its concrete counterpart. Proof obligations that 
establish the consistency of refinements are : 

For initialisation Init : [Init R ](Init s )J 
For events e of Interface^) : I A J => [e R ](e s )J 
For the new events ne R : I A J => [ne R ](sk\p)J 

New events cannot indefinitely take the control, i.e. the refined system cannot 
diverge more often that the abstract one. So, a variant V is declared in the refined 
system, as an expression on a well-founded set (usually the natural numbers), 
and the new events must satisfy (v is a fresh variable) : 



V is a natural expression : I A J => V G N 

New events ne R decrease the variant : J A J => [u := V][ne fl ](y < w) 

Finally, a proof obligation of liveness preservation is usually required. If S con- 
tains to events and 1Z contains p new events, then: 

IAJ^> (V™ ! GW(ef ) => (V™ ! GW(ef ) V VLi Guanine?))) 

Traces associated to refinements are defined as for the systems. 

3 Symbolic labelled transition systems associated to B 
systems 

3.1 Symbolic transition systems 

We define symbolic labelled transition systems: 

Definition 2 (Symbolic labelled transition system) A symbolic labelled tran- 
sition system (SLTS) is a J^-uple (N, Init, U, W) where 

- N is a set of states, and Init is the initial state (Init G N) 

- U is a set of labels of the form (D, A, e), where D and A are predicates and 

e is an event name 

- W is a transition relation W C F(N x U x N). 

A transition (E, (D, A, e), F) means that, in state E, the event e is enabled 
if D holds and, starting from state E, if event e is enabled, then it reaches state 
F if A holds. Predicate D is called the enabledness predicate and A is called the 
reachability predicate. 

States N are interpreted as subsets of variable spaces on variables x. So, the 
interpretation of N is given by a function X such that 1(E) is a predicate on free 
variables x which characterizes the subset represented by E. In the next defini- 
tion, we determine the actual conditions to cross a transition from a particular 
state value x\ of E\ to xi of E% by an event e which is defined in an event- B 
system S. For that, e must be enabled in x\, X2 must be reachable from x\ by 
e, and (x\,x<i) must belong to the before-after predicate of e: 

Definition 3 (Transition crossing) Let (Ei, (D, A, e), E2) be a transition of 
a SLTS T on a system S, and given x\ and X2 some values of the state variables 
x which satisfy the invariant of S , then a crossing from x\ to X2 by this transition 
is legal if and only if : 1. [x := xi]{I(E\) ADAi) 

2. [x,x' :— xi,x 2 ] prd x (Action(e)) 

3. [x := X2]1(E 2 ) 
Such a legal transition crossing is denoted by : 

(Ei,xi) ~*( D ' A ' e U (£2,2:2) 

Now, we introduce the notion of path in a symbolic labelled transition system. 
A path is a sequence of event occurrences, starting from the initial state, which 
goes over a transition system through legal transition crossings. 



Definition 4 (Paths) Given a symbolic labelled transition system T on a sys- 
tem S, a sequence of event occurrences cq e n +i is a path in T if there exists 

a list of states E , ■ ■ ■ ,E n+ \ of N , with E n = Init-r, and a list of transitions 
(Di,Ai,ei),i G 0..n, such that : 

3x , • ■ • , x n +i ■ {N!= Q {{Ei,Xi) (E i+1 ,x i+1 ))) 

The set of all the finite paths of T is called Paths (T). 
3.2 Construction of states and transitions 

The aim of this section is to show how to compute a SLTS, from an event- B 
system S and given a set of states N. First, to build the states N, consider a 
list of predicates {Pi, . . . , P„} on the variable space. We require that this set is 
complete with respect to the invariant, i.e. all the states specified by the invariant 
are included in the states determined by the Pi predicates, i.e. 

n 

i => V 'Pi 

i=l 

Then, the states of the SLTS are N = {Inits, E\, . . . , E n } with the interpretation 
defined by: 

1 (Inits) = true 1(Ei) = Pi A I, i G l..n 

We denote by Nl the set — {Inits}- From the completeness property above 
and the definition of N, we get: I <^> \J™ =l I(Ei). 

Now, we express the conditions to ensure that a symbolic labelled transition 
system T represents the same set of behaviors as the associated system S. For 
that, in a starting state E, the cnabledness condition must be equivalent to the 
guard of the event e, and if the target state is F, the reachability condition must 
be equivalent to the possibility to reach F through e, when the enabledness 
predicate holds, so the condition: 

Condition 1 (Valid transitions) Let S be a system, E and F two states in 
N as defined above, and e an event, then the transition (E,(D,A,e),F) is valid if 
and only if predicates D and A satisfy : 

a) 1(E) (D & Guard(e)) 

b) 1(E) A Guard(e) => (A & (Action(e))l(F)) 

Notice that, by applying the definition of the conjugate weakest precondition, 
condition b) is equivalent to : 

1(E) A Guard(e) => (A ^> 3x' ■ (prd x (Action(e)) A [x := x']l(F))) 

A SLTS with all the transitions valid with respect to a system S is called a valid 
symbolic labelled transition system. 



Theorem 1 (Traces and paths equality) Let S be an event-B system with 
invariant I and events Ev and let T be a valid symbolic labelled transition system 
built from S, then: 

Traces (S) = Paths (T) 

Proof: We prove that, for all t, t 6 Paths(T) & t e Traces(S). 

The path t = eo-ei e„ is a path for the state sequence Eq, E\, ... , E n+ \ iff 

(Definition 4): 3x , . . . , x n+1 ■ A? =0 ((^i. *i) -> (D - A *^ ) - (£7 i+ i,x i+ i)) 
By using Definition 3, we get: 

3x , . . . ,a; n+ i • A"=o([ x := AAA Aj) 

A [a;, a;' := Xi,x i+1 }prd x (Action(ei)) A [a; := a; i+ i]X(.E; + i)) 
By Condition 1, one can replace Dj by Guard(ei) and Ai by 3x'-(prd 2 .(^4ctton(e»))A 
[a; := x']I(Ei + i)). The formula above is simplified and becomes: 

(1) 3x , . . . ,x n+ i ■ /\" =0 {[x := Xi]{l{Ei) A Guard{ei)) 

A [x, x' := Xi, Xi+ijprd^, (Action (e^)) A [a; := £j + i]X(.Ei + i)) 
We must prove that this formula is equivalent to the characterization of the 
traces (Property 1): 

(2) 3x , . . .,x n+1 ■ /\™ =0 ([x := Xi\Guard(ei) 

A [x, x' :— Xi, x i+ i]prd x (Action(ei)) A [x := Xi + \]I) 
Implication (1) =>■ (2) is verified because states Ei are such that I(Ei) => I (Sec- 
tion 3.2). To prove (2) => (1), we must exhibit a list of states E , E\, ... , E n+ \ 
such that these states satisfy (1). This follows from the fact that 1(Eq) = true 
and from / => V"=i ^-(-^i)> which ensures that one of the states I(Ei) necessarily 
holds when / hold. □ 



3.3 Labelled transition systems for the refinements 

We propose now the construction of a symbolic labelled transition system for 
the refinements. Our aim is to highlight the links between abstract and concrete 
transition systems, while preserving the overall structure of the abstract system. 
One aspect of the refinement is the change of the variable representation and 
redefinition of the events of the abstraction, according to the new representation. 
The point is taken into account by the notion of state projection. 

In the following, S is a specification, 1Z is its refinement with gluing invariant 
L, and T s is a symbolic labelled transition system for S. States E s and F s are 
states in T s ■ We assume that the variable set x s of S is disjoint to the variable 
set x R of the refinement. If some variables of the specification are kept in the 
refinement, they can be renamed and an equality between both variables is added 
to the invariant. 

Definition 5 (State projection) Let S be a system with variables x s and 1Z 
be the refinement of S according to L. A state E R of , E R ^ Init-jz is the 
projection of E s of T s , denoted by E R = Proj L (E s ), iff: 

1(E R ) & 3x s ■ (L A 1{E S )) 



We propose to build a SLTS, called Proj L (T S ), in which states are automat- 
ically deduced from abstract states and gluing invariant. The SLTS projection 
Proj L (T S ) of the refinement TZ of system S with gluing invariant L is such that: 
the initial state is any q with X(q ) = true; the other states of the projection 
are the projections of abstract states, i.e. N1 R = {Proj L (q) \ q G Al 5 }. The 
transitions are (E R , (D' , A', e R ), F R ) where e R G TZ and D 1 , A' are such that 
Condition 1 is satisfied. A transition (E R , (D' , A' , e R ), F R ) is said a projection of 
transition (E s , (D, A, e s ),F s ) iff E R = Proj L (E s ), F R = Proj L (F S ) and event 
e R is the refinement of e s . By construction, Paths{Proj L (T S )) = TracesiJZ). 
This equality can be proved in the same way as in Theorem f . 

Property 2 (Transition projection) With the definitions above, 

let (E R , (D',A',e R ),F R ) be the projection of transition (E s , (D, A, e s ),F s ), 

then we have: 

1(E S ) A L A D'^D 

This property says that any transition enabled from a state Proj L (E S ) in a 
refinement TZ actually must be enabled in specification S (if the refinement is 
proved correct). Property 2 can make the computation of the transitions sim- 
pler. Indeed, if e G Interface(S), then, for all the transitions (E s ,e,F s ) of the 
abstraction, it is only necessary to examine the transitions (Proj L (E s ) 7 e,E') 
with E 1 G N1 R . No other transition can be labelled by e from this state. 

Another key aspect of refinement is the refinement of behaviors. New events 
may be introduced that make the actions more detailed. These new events are 
not observable at the abstract level, as the stuttering in TLA [II]. Very often, 
new variables are introduced. Thus, it is useful to visualize the states referring 
to these variable changes. In order to preserve the structure of the abstract 
system, we choose to refine each abstract state in an independent way. So, the 
transitions, relative to events which belong to Interface(S) , are preserved by the 
introduction of hierarchical states. 

Definition 6 (Hierarchical states) A set of sub-states {E R , . . . , E R } can be 

associated to a super-state Proj L (E S ) of TZ if and only if 

m 

\/l(E R )^l(Proj L (E s )) 
i=i 

In a refined system, the user must decide what projections of abstract states 
are decomposed and s/he must provide the predicates of the decomposition. 
If the abstract states are disjoint, then the transitions associated to the new 
events appear only between the sub-states of a hierarchical state. An example 
of refinement with decomposition of states is given in Section 4.4. 

4 The GeneSyst tool 
4.1 Presentation 

The GeneSyst tool is intended to generate a symbolic labelled transition system 
T from an event-B system S and a set of states N. Such a generated SLTS 



will be denoted by T(S,N). The input of the tool is a B component, where 
the assertions clause contains the formula Pi V ... V P„, which characterizes 
the list of predicates {Pi, . . . , P„}. By this way, the condition of completeness 
(section 3.2) is generated as proof obligation. 

We give a sketch of the algorithm which computes the transitions of T(S, N) : 
it uses three main variables: the set of visited states, visited, the set of processed 
states, processed, and the set of computed transitions tr. First, the initial state 
is put in the visited set. Then each state E in the visited set is processed: this 
consists in computing the transitions (E, (D, A, e), F) with all events e to all 
non-initial states F of the system. Predicates D and A are determined following 
the algorithm defined in the following section. If D or A are not false then the 
transition (E, (D,A,e),F) is added to tr, and if F has not been processed, it 
is put in the visited set. After the processing of state E, E is removed from 
visited and put in set processed. When visited is empty, then tr contains all 
the computed transitions of T(S, N) and processed contains the set of reachable 
states. The algorithm terminates, because the set of states to be visited is finite 
(bounded by the cardinal of N). This algorithm guarantees that the resulting 
SLTS is a valid transition system for S, with given states N. 

4.2 Proof obligations 

A subprocedure of the algorithm is to determine effectively the enabledness 
predicate and the reachability predicate, given a triple (E,e,F). For sake of 
usability of the resulting transition system, it is interesting to examine three 
cases: predicates are true, false or other. This information can be obtained by 
proof obligations. In Fig. 1, we give the conditions for the calculus of these 
predicates. Obviously, if D and/or A is false, then the transition is not possible. 





Proof obligations 


D for (E, e, F) 


(1) 

(2) 
(3) 


Vx • (1(E) Guard (e)) 
Va; ■ (1(E) -, Guard (ej) 
3x ■ (1(E) A Guard (e)) 


true 
false 
Guard(e) 




Proof obligations 


A for (E, e, F) 


(4) 
(5) 
(6) 


Vx • (1(E) A Guard(e) => (Action(e))l(F)) 
Va; ■ (1(E) A Guard(e) [Action (e)]-. 1(F)) 
3x ■ (1(E) A Guard(e) A (Action(e))l(F)) 


true 
false 
(Action(e))l(F) 



Fig. 1. Proof obligations for enabledness and reachability 



In practice, the GeneSyst tool computes the proof obligations (POs) above 
and interacts with AtelierB to discharge the POs. For each triple (E, e, F): 

1. if proof obligation (1) is automatically discharged then D is true. 

2. if proof obligation (2) is automatically discharged then D is false and tran- 
sition (E,e,F) does not occur in the resulting T(S,N). 

3. otherwise, D is Guard(e) by default. 



Then, after cases 1. and 3., GeneSyst computes the proof obligations for deter- 
mining the reachability predicate A. 

4. if proof obligation (4) is automatically discharged then A is true. 

5. if proof obligation (5) is automatically discharged then A is false and tran- 
sition (E,e,F) does not occur in the resulting T(S,N). 

6. otherwise, the transition is kept with (Action(e)) 1(F) as A, by default. 

We can notice that Condition 1 about the validity of the transitions is well 
satisfied by construction. The by default cases in 3. and 6. correspond to several 
possibilities. Either there exist values in state E for which the transition is cross- 
able (guard of e is true and state F is reachable), or there are not (the guard 
is false or state F is not reachable). However, in both possibilities, these tran- 
sitions are included in the resulting transition system. To manage this feature, 
we define the notion of minimal symbolic labelled transition system. 

Definition 7 (Minimal SLTS) A minimal SLTS is a SLTS where all the tran- 
sitions are valid, i.e. satisfy a) and b) of Condition 1, and also satisfy: 
c) D jfy false and A <fc false 

A SLTS built by GeneSyst is minimal if all the proof obligations of D and A 
have been effectively discharged in step 1. or 2. and step 4. or 5. in the algorithm 
above. To minimize the number of by-default transitionss, we have designed two 
variants of the algorithm. The first optional alternative of the algorithm is to 
change cases 3. and 6. into: 

3'. if proof obligation (3) is automatically discharged, then D is Guard(e) by 

proof, otherwise, D is Guard(e) by default. 
6'. if proof obligation (6) is automatically discharged, then A is (Action(e)) 1(F) 

by proof, otherwise, the transition is kept with (Action(e)) 1(F) as A by 

default. 

Another option of the tool allows the user to get the POs which have not been 
automatically discharged. Then, s/he can do an interactive proof to complete 
the work and return the information that the PO is discharged or not. However, 
the interactive mode is not very practicable when there are a great number of 
proof obligations that are not automatically discharged. It becomes useful to 
check actually the absence of some critical transitions (cases 2. and 4.). 

4.3 Transition systems associated to the Demoney case study 

In Fig. 2, we give an example of transition system generated from a subset of 
the abstract specification of the Demoney case study. The B machine is provided 
in appendix. We just have represented four methods imposed by the Demoney 
specification [16]: InitializeTransaction, CompleteTransaction, Reset and Get- 
Data. The two methods InitializeTrans action and CompleteTransaction have to 
be executed in sequence. If they are called in the wrong order then an error must 



be returned. Moreover, any other methods cannot be invoked between them, ex- 
cept the method Reset which models the extraction of the card from the terminal. 
If it is called during a transaction, all the internal variables must be restored at 
their initial values. Finally, method GetData has been defined to represent any 
other method which plays a neutral role with respect to transactions. 

Let us notice that our model has been expressed with events. In the applet De- 
money, methods have neither parameters nor result, because they communicate 
through a global variable, named APDU, which allows the information transfert 
between the card and the terminal. An error can be returned by means of the 
same variable. Finally, methods have no precondition, because they are callable 
at any time. So the transformation of methods in events is straightforward. 

In the diagrams generated by GeneSyst, transitions are prefixed by the infor- 
mation about predicates D and A. A predicate denoted by "[ ]" means true, while 
"[G]" means that the transition is computed by cases 3. or 6. (see section 4.2). 



[ J [ J InitializeTransaction 
[ ] [ ] CompleteTransaction 



[ ] [G] GetData 
[ ] [ ] InitializeTransaction 
[ J |G] CompleteTransaction 



L J I J Reset 
[ J I J GetData 
[III InitializeTransaction 




[ ] [ ] Reset 
[ J [GJ GetData 
[ ] [GJ InitializeTransaction 
I J |GJ CompleteTransaction 



Fig. 2. Transition system associated to the error detection in the Demoney specification 



Fig. 2 points out cases in which errors can occur. Transitions have no enabled- 
ness condition, because all the guards are true in the model. Some reachability 
conditions do not reduce to true, as for the event GetData, which is defined by: 

GetData = if EngagedTrans = TRUE then 

Error := TRUE || EngagedTrans := FALSE 
else Error := FALSE end; 

From state Error = FALSE, event GetData can reach the state Error = TRUE with 
the condition EngagedTrans = TRUE and stays in Error = FALSE otherwise. Let us 
remark also that GetData is enabled in state Error = TRUE and always reaches 
state Error = FALSE because of the invariant Error = TRUE => EngagedTrans = 
FALSE. 



4.4 Transition system associated to a refinement of Demoney 

In our refinement of Demoney, the boolean variable Error is changed into a value 
of a given set StatusType, which intends to describe error codes, as imposed by 
the specification [16]. In the same way, the boolean variable EngagedTrans is 
refined into a value of a given set TransactionType, which indicates the exact 



type of the current transaction. Finally, we have introduced the channel with 
two levels of security (FALSE and TRUE). All this information is declared in the 
invariant below (see also the refinement in appendix): 



INVARIANT 

StatusWord £ StatusType A CurTransaction £ TransactionType A 
Channells Secured £ BOOL A 

((Error = FALSE) & (StatusWord = ISODk)) A 
((EngagedTrans = FALSE) <4> (CurTransaction = None)) A 
((CurTransaction ^ None) =>• (Channells Secured — TRUE)) A 
((StatusWord ± ISODk) =>■ (CurTransaction = None)) 



Fig. 3 is built from this refinement. State Error = FALSE, which corresponds 
to StatusWord = ISOJDk, is split into two states according to that a transaction 
is engaged or not. 



Qlnit 



I Init 



J InitializeTransaction 
] CompleteTransaction 



Error = TRUE 




StatusWord * ISO_Ok 




] InitializeTransaction 
] CompleteTransaction 



Error = FALSE 



Reset 
GetData 




] [GJ InitializeTransaction 
: ] [G] InitializeTransaction 



[ ] [ ] GetData 
I InitializeTransaction 



Fig. 3. Transition system associated to the refinement of the error detection 



As expressed in Definition 6, the predicate given to GeneSyst to describe the 
states has to be a conjonction of equivalences between an abstract state and a 
disjonction of refined states. This predicate is written in the assertion clause. 
For example, the assertion below has been used to generate Fig. 3. 

((Error = TRUE) <4> ((StatusWord ^ ISOJDk A CurTransaction = None) 

V (StatusWord ^ I SO -Ok A CurTransaction N one))) 

A 

((Error = FALSE) <S> ((StatusWord = ISOJDk A CurTransaction = None) 

V (StatusWord = ISO.Ok A CurTransaction / None))) 

With the splitting of the state Error = FALSE, transition conditions are 
simplified in true or false or, in the worst case, are unchanged. For example, 
in Fig. 2, the transition labelled by [][G]CompleteTransaction and going from 
Error = FALSE to Error = TRUE is, in Fig. 3, going from StatusWord = ISOJDkh 
CurTransaction = None to StatusWord 7^ ISOJDk A CurTransaction — None with 



the label [}[}CompleteTransaction. So, its reachability has been made more pre- 
cise. The same effect occurs on transition [][G]CompleteTransaction going from 
Error = FALSE to Error = FALSE, which is refined by [][]CompleteTransaction 
going from Cur Trans action / None to Cur Trans action = None in the super-state 
Error = FALSE. These two specializations are directly due to the introduction of 
the CurTransaction variable. 

5 Verification of Security Properties on Demoney 

In this section we propose a formalism to express properties relative to security 
aspects and we show how GeneSyst can be used to verify these properties. We 
will next give a concrete example relative to the Demoney case study. 

5.1 Properties 

Generally, security is designed and implemented through different levels of ab- 
straction. Security policies are defined by a set of rules according to which the 
system can be regulated, in order to guarantee expected properties, as confi- 
dentiality or integrity Security policies are then implemented through software 
and hardware functions, called security mechanisms. Such an approach has been 
adopted by the Common Criteria norm [8] which proposes, through the notion 
of assurance requirements, a catalogue of security policies and a hierarchy of 
mechanisms. 

In this paper we focus on security properties relative to constraints on the 
global behavior of the system, as authentication procedures or access control. In 
this case, security requirements can be seen as constraints on the execution order 
of atomic actions, as operation calls. F. Schneider claims in [18] that automata 
are a well-adapted formalism which can, both, be used to specify some forms of 
security policies and to control implementations during their execution. On the 
other hand, K. Trentelman and M. Huisman [22] propose a logic that can be 
used also to express some forms of security properties, as temporal properties 
on JML specifications. 

We adopt a formalism based on logic formulas, which allows us to point 
out expected behaviors either in specifying correct executions, or in specifying 
security violations. That offers a good flexibility and is suitable to describe as well 
open policies as closed policies, respectively relative to negative authorizations 
and positive authorizations [17]. 

5.2 Predicates of security properties 

Security properties are often represented as a list of first order logic formulas that 
have to be verified. We want to define some predicates to make the expression 
of these formulas easier. Predicates that we introduce express the ability of an 
event to start from a state (Enabled and AlwaysEnabled) and the existence of a 
transition between two states (Crossable and AlwaysCrossable). 



Definition 8 (Enabled, AlwaysEnabled, Crossable and Always Cross able) 
Given p\ and p 2 two state predicates and an event ev from a system S with 
variables x, then: 

Enabled (pi,ev) = 3x ■ (p\ A Guard(ev)) 

AlwaysEnabled(pi,ev) = Vx • (p\ => Guard(ev)) 

Crossable(pi,ev 7 p 2 ) = 3x ■ (pi A (ev)p 2 ) 

AlwaysCrossable(pi 7 ev,p 2 ) = Vx • (pi [ev]p 2 ) 

Let us note that if Enabled(pi,ev) false, then, for each predicate p 2 , 
AlwaysCrossable(pi,ev,p 2 ) will be true instead of false, which is the intuitive 
value expected. In the same way, if p\ is equivalent to false then AlwaysEnabled 
and AlwaysCrossable are always true. Moreover, we can notice that: 

Crossable(pi 7 ev,p 2 ) => Enabled (pi,ev) 
From this definition we can deduce the properties below, relative to the impli- 
cation: 

Property 3 Given pi, p 2 and p$ three predicates and an event ev then: 

~ if Pi =^ P3 and Enabled (pi, ev) then Enabled (p^,ev) 

~ if P3 Pi and AlwaysEnabled (pi, ev) then AlwaysEnabled (p%,ev) 

— if pi => pz and Crossable(pi 7 ev,p 2 ) then Crossable(p 3 ,ev 7 p 2 ) 

— if p 2 => P3 and Crossable(p\,ev,p 2 ) then Crossable(p\, ev,p^) 

— if P3 Pi and AlwaysCrossable(pi,ev,p 2 ) then AlwaysCrossable(p3,ev,p 2 ) 

— if p 2 pz and AlwaysCrossable(pi,ev 7 p 2 ) then AlwaysCrossable(pi,ev 7 pz) 

Here are two examples: 

Reactivity of a system. The JavaCard specification imposes that any APDU 
instruction is callable at any time. Given S a system and / its invariant, then 
this formula can be expressed as follows: 

Vew • (ev e Interface(S) => AlwaysEnabled (I , ev)) 

Unicity of the ways to reach a state. In some cases, like access control, we 
want to impose that the only way to reach a state P is to execute a particular 
event Begin. If / is the invariant of <S, then this property can be expressed as 
follows: 

Mev ■ (ev £ Interface(S) A e«/ Begin AlwaysCrossable(I , ev, -*P)) 
5.3 Property checking using GeneSyst SLTS 

Security properties could be verified on B specifications, using definition 8. Nev- 
ertheless, in some cases, the SLTS produced by GeneSyst can be directly ex- 
ploited. Then, the verification consists in using syntactic information relative to 
enabledness and reachability of transitions. Properties 4-7 list the different cases 
where the predicates above can be directly established from a symbolic labelled 
transition system. 



Properties 4-7 share the following hypothesis: Given an event e and q\, q 2 
two states from a SLTS T , such as I{qi) & false and (qi, (D, A, e), q 2 ) € Wt, 
then predicates Enabled, AlwaysEnabled , Crossable and Always Cms sable can be 
determined as follows:. 



Property 4 (Enabledness condition - general case) 

1. D = true => Enabled (qi, e) 

2. D = false => -1 Enabled (qi,e) 

3. D = true => AlwaysEnabled(qi,e) 
4- D = false => —1 AlwaysEnabled (qi, e) 

If the SLTS used to verify the property is minimal, then Property 4 can be 
enlarged: the conditions are necessary (and sufficient) and conditions 1 and 4 
are refined. 



Property 5 (Enabledness for minimal SLTS) 

1. D ^ false Enabled(q\,e) 

2. D = false -1 Enabled (qi,e) 

3. D = true AlwaysEnabled(qi,e) 
4- true ^AlwaysEnabled(qi,e) 

In the same way, syntactic conditions to check Crossable and AlwaysCrossable 
predicates are: 

Property 6 (Reachability condition - general case) 

5. A = true => Crossable(qi 1 e 1 q 2 ) 

6. A = false V D = false => ^Crossable(qi,e,q 2 ) 

7. A = true A 

V<7i • (<Z2 # qi => (51, (D, A 2 , e), qi) g Wt) => Alw <ay <s Cross able (qi,e, q 2 ) 

8. A = false => ^AlwaysCrossable(qi,e 7 q 2 ) 

Cases 7 and 8 are not symetric, as it would be expected, because, syntacticaly, 
we can just compare names of states, not the intersection of their interpretation. 
Just as for enabledness, the conditions can be enlarged, when the SLTS is min- 
imal, as follow: 

Property 7 (Reachability for minimal SLTS) 

5. A^ false <^> Crossable(qi 1 e 1 q 2 ) 

6. A = false V D = false <^> ^Crossable(qi,e,q 2 ) 

8. A ^ true => -^AlwaysCrossable(q\ 1 e 1 q 2 ) 

Cases 7 and 8 are just sufficient conditions because of the limitation of the 
syntactic verification. Case 7 is not present in Property 7 because it is the same 
as in Property 6 Finally, Property 3 allows the deduction of derived properties 
from the four properties above, by weakening or strenghtening the states. 



5.4 Example of a property checking 

In this section, we develop a real example of Demoney property and we do its 
verification by using the SLTS given in Figure 3. In the Demoney specification 
[16], the two APDU instructions InitializeTrans action and CompleteTransaction 
have to be executed in sequence, without any other instructions between them 
and without reaching any error state, to make a transaction. However, the card 
can be withdrawn at any time (modelled by the Reset event) without generating 
any error. Transaction atomicity property can be decomposed in five formulas 
given below, where I stands for the invariant of the Demoney specification. More- 
over, SLTS of Figure 3 is minimal and events are always enabled from all state 
of the SLTS. Finally, note than the invariant I is equivalent to the union of all 
state predicates (Section 3.2). 

Formula 1: There exists at least a value in / such that the event Initialize- 
Transaction can reach CurTransaction ^ None: 

Crossable{I , InitializeTransaction, CurTransaction ^ None) 
Predicate CurTransaction ^ None directly corresponds to a state predicate. 
Since there exists a transition from CurTransaction = None A StatusWord = 
ISO-Ok to CurTransaction ^ None, labelled with [ ][G]InitializeTransaction, 
then we can use case 5 of Property 7 and conclude that the Formula 1 is true. 

Formula 2: For all values, the event InitializeTrans action goes into the state 
CurTransaction ^ None or into an error state: 

AlwaysCrossable (I, InitializeTransaction, 

CurTransaction ^ None V StatusWord =/= I SO -Ok) 
CurTransaction ^ None and StatusWord ^ ISO-Ok are two state predicates, 
and all the transitions labelled with InitializeTrans action go only in one of these 
states. Then, due to case 7 of property 6, this formula is true. 

Formula 3: From CurTransaction^N one, all events, but CompleteTransaction 
and Reset, go to an error state: 

Ve • (e G Interface(S) A e / CompleteTransaction A e ^ Reset => 
AlwaysCrossable(CurTransaction ^ None, e, StatusWord ^ ISO-Ok) 
The two predicates correspond to state predicates and the only events which 
go elsewhere than StatusWord ^ ISOJJk from CurTransaction ^ None are 
CompleteTransaction and Reset. Thus Formula 4 is true (case 7 of Property 6). 

Formula 4: Except InitializeTransaction, no event can reach CurTransaction 
^ None: 

Ve • (e G Interface(S) A e / InitializeTransaction => 
Alw ays Cross able (1 ,e, CurTransaction = None)) 
Predicate CurTransaction = None is the union of two existing state predicates. 
So, we have to check if there exists an event, different from InitializeTransaction, 
that can reach CurTransaction ^ None. Since it is not the case, this formula is 
true (case 7 of Property 6). 



Formula 5: No transition labelled by CompleteTrans action or Reset is reflexive 
on state Cur Trans action ^ None: 

-^Crossable(CurTransaction ^ None,CompleteTransaction, 
CurTransaction ^ None) 

and -^Crossable{CurTransaction ^ None, Reset, CurTransaction ^ None) 
CurTransaction ^ None corresponds to a state predicate and no Complete- 
Transaction or Reset reflexive transition occurs. Thus this formula is true (case 5 
of Property 7). 

The model of Demoney is thus correct relatively to the atomicity security 
property of transactions. However, during the realisation of this example, which 
is a simplified Demoney applet, we found three errors due to an erroneous sim- 
plification of our complete model of Demoney. 

The originality of this approach is to have brought back, under some hypothe- 
ses, the verification of security properties to a syntactic checking. However, it 
is important to be careful about the real value of the crossing conditions gen- 
erated by GeneSyst. Indeed, if some proof obligations are not (automatically) 
discharged, the transitions system will have by-default transitions. Then, to 
properly exploit the information, we have to be sure that the property to be 
verify can be checked on a non- minimal SLTS. 

6 Related works and Conclusion 

The work presented here is in line with the ideas presented in [5] , itself inspired 
by [9] . In [5] , the authors propose the construction of a labelled transition sys- 
tem which is a finite state abstraction of the behavior of an event- B system. 
The existence of transitions is determined by proof obligations, as here, but 
the resulting transition system does not contain any information about transi- 
tion crossing. Moreover, the paper does not consider the refinement step in the 
diagram representation. 

Other work is devoted to the translation of dynamic aspects described by 
statecharts in the B formalism (for instance [13,20]). These approaches are in- 
verse of ours, because they go from a diagrammatic representation to an encoding 
in a formal text. Their objective is to build a B model from UML descriptions. 
On our side, we suppose that the model has been stated and we are interested 
in representing the precise behavior of the system with respect to (a part of) 
variables, in order to check properties, or to validate the model against the re- 
quirements. 

A similar approach has been envisaged for TLA [12] and extended in [6, 7] 
to take in account liveness properties and refinement. As in [5], the generated 
diagrams are abstractions of the system behavior. 

Several tools are dedicated to the analysis of the behavior of B components by 
the way of the animation of machines [4] or by local exhaustive model checking 
[14] . Even if some of them allow the generation of symbolic traces, these tools can 



be considered as "testing" tools. They provide particular execution sequences of 
the system, not a static representation of all the behaviors. In [23], the authors 
describe the generation of statecharts from event-B systems, but their approach 
suffers from several restrictions and their diagrams are not symbolic. 

In this paper, we have presented the GeneSyst tool, its logical foundations 
and its application to the verification of security properties. In the first part, 
we introduced the definition of traces of event-B systems and refinements. We 
formalized the notion of symbolic labelled transition systems, with transitions 
decorated by enablcdness and reachability predicates. This gives a complete and 
precise view of the behavior of the system, which can be exploited for various 
objectives. 

We described the algorithm that is implemented to generate a SLTS from a 
B system and a set of states, characterized by predicates. The computation of 
effective transitions between states is performed by proving proof obligations. 
Due to the indecidability of the proof process, we have the choice between two 
kinds of (non exclusive) results: the generation is automatic, but we can get 
more transitions than in the real system, or the user completes interactively 
the non-conclusive proofs and then, the resulting automaton reflects exactly the 
behavior of the system. 

The user can take profit of the freedom degree achieved by the choice of the 
states, to obtain the best analyses useful for him/her purpose. Non classical ver- 
ification techniques can be designed and implemented at this stage, to assess or 
to validate the model, as it was shown in the last part of the paper. This opens 
a large field of research in the domains of security properties, confidentiality, 
access control, validation of models with respect to the requirements, automatic 
documentation of specifications, etc. Our present research work is to develop 
a set of techniques in the GECCOO 2 project to express and to check security 
properties, as it was sketched in the paper. We want to investigate the extrac- 
tion of states from the specification of property automata, the use of refinement 
to split states and achieve a suitable level of decomposition in order to check a 
property. Another work is to deal with complex B models (several refinement 
chains together with composition clauses sees, includes, etc.), either by com- 
posing partial labelled transition systems, or by flattening a structured model 
before computing the whole associated SLTS. 
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Appendix 

Machine of the Demoney specification (diagram in Fig. 2, Section 4.3): 
machine Demoney 

VARIABLES 

Error, EngagedTrans 

INVARIANT 

Error G BOOL A EngagedTrans e BOOL A 
(Error = TRUE => EngagedTrans = FALSE) A 
(EngagedTrans = TRUE .Error = FALSE) 

ASSERTIONS 

/* The assertion provides the states for tool GeneSyst */ 

/* Here, only two states are considered according to the Error values */ 

Error = FALSE V Error = TRUE 

INITIALISATION 

Error := FALSE || EngagedTrans := FALSE 

OPERATIONS 

Reset = begin EngagedTrans := FALSE || Error := FALSE end; 
GetData = 

if EngagedTrans = TRUE then 

Error := TRUE || EngagedTrans := FALSE 

else Error := FALSE 

END; 

InitializeTransaction = 

if EngagedTrans = TRUE then 

Error := TRUE || EngagedTrans := FALSE 

ELSE 

ANY SW WHERE SW € BOOL THEN 

Error := SW \\ EngagedTrans := boo\(SW = FALSE) 

END 
END; 

CompleteTrans action = 

if EngagedTrans = FALSE then 

Error := TRUE 
else Error := FALSE || EngagedTrans := FALSE 

END 

END 



Refinement of the Demoney specification (diagram in Fig. 3, Section 4.4): 

refinement Demoney _R1 
refines Demoney 

SETS 

Trans actionType = {Credit, Debit, None}; 
StatusType = {ISO.Error,ISO.Ok} 

VARIABLES 

StatusWord , CurTransaction, ChannellsSecured 



INVARIANT 

StatusWord € StatusType A CurTransaction € Trans actionType A 
ChannellsSecured e BOOL A 
((StatusWord = ISO-Ok) O (Error = FALSE)) A 
((EngagedTrans = TRUE) <S> (CurTransaction =fc None)) A 
((CurTransaction 7^ None) => ChannellsSecured — TRUE) A 
((StatasWord / ISO.Ok) (CurTransaction = None)) 

ASSERTIONS 

/* Each abstract state is decomposed in two concrete states */ 
/* One of these states is not reachable */ 
((Error = TRUE) & 

((StatusWord / ISO-Ok A CurTransaction = None) 

V (StatusWord / I SO. Ok A CurTransaction =£ N 'one))) 

A 

((Error = FALSE) « 

((StatusWord = ISO-Ok A CurTransaction — None) 

V (StatusWord = ISO-Ok A CurTransaction / None))) 

INITIALISATION 

Status Word := ISO-Ok \\ ChannellsSecured := FALSE || 
CurTransaction := None 

OPERATIONS 

i?eset = BEGIN 

StatusWord := ISO-Ok \\ ChannellsSecured := FALSE || 
CurTransaction := None 
END; 
GetData — 

if CurTransaction None then 

StatusWord := ISO -Error \\ CurTransaction := None 

ELSE 

Status Word := ISO-Ok 
END; 

InitializeTrans action — 

if CurTransaction / A^one V ChannellsSecured = FALSE then 
StatusWord := ISO-Error \\ CurTransaction := None 

ELSE 

StatusWord :£ StatusType; 

if StatusWord = ISO-Ok then 

CurTransaction :€ {Debit, Credit} 

END 
END; 

CompleteTransaction — 

if CurTransaction = None then 
StatusWord := ISO-Error 

ELSE 

CurTransaction := None j StatusWord := ISO-Ok 

END 

END 
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Abstract. In this paper, we present a method and a tool to build sym- 
bolic labelled transition systems from B specifications. The tool, called 
GeneSyst, can take into account refinement levels and can visualize the 
decomposition of abstract states in concrete hierarchical states. The re- 
sulting symbolic transition system represents all the behaviors of the 
initial B event system. So, it can be used to reason about them. We il- 
lustrate the use of GeneSyst to check security properties on a model of 
electronic purse. 



1 Introduction 

Formal methods, such as the B method [?], ensure that the development of an 
application is reliable and that properties expressed in the model are satisfied by 
the final program. However, they do not guarantee that this program fulfills the 
informal requirements, nor the needs of the customer. So, it is useful to propose 
several views about the specifications, in order to be sure that the initial model 
is suitable for the customer and that the development can continue on this basis. 
One of these important insights is the representation of the behavior of programs 
by means of diagrams (statecharts). Moreover, some particular views, if they are 
themselves formal, can provide new means to prove properties that cannot easily 
be checked in the first model. 

In this paper, we present a method and a tool to extract a labelled transition 
system from a model written in event- B. The transition system gives a graphical 
view and represents symbolically all the behaviors of the B model. The method 
is able to take into account refinement levels and to show the correspondence 
between abstract and concrete systems, by means of hierarchical states. 

We present also an application of this tool, namely, the verification of secu- 
rity properties. The security properties assert the occurrence or the absence of 
some particular events in some situation. They are a case of atomicity property 
of transactions. This is illustrated by an example of specification of an electronic 
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purse, called Demoney[?,?], developed in the SecSafe project [?]. This case study, 
written in Java Card [?] , is an applet that has all the facilities required by a real 
electronic purse. Indeed, the purse can be debited from a terminal in a shop, cred- 
ited by cash or from a bank account with a terminal in a bank or managed from 
special terminal in bank restricted area. Transactions are encrypted if needed 
and different levels of security are used depending on the actions. Demoney also 
supports to communicate with another applet on the card, for example, to man- 
age award points on a loyalty plan. The specification of Demoney is public in 
version 0.8 [?], but the source code is copyrighted by Trusted Logic S.A. 1 . 

In Section 2, we recall the main features of event- B systems and refinements. 
We introduce a notion of behavioral semantics by the way of sequences of events. 
In Section 3, we define symbolic labelled transition systems (SLTS) and the 
links between SLTS and event-B systems are stated. In Section 4, we present 
the GeneSyst tool and an example of generation of SLTS dealing with the error 
cases in the Demoney case study. Section 5 presents security properties required 
in the application and shows how the GeneSyst diagrams can be used to check 
these properties. Then, we review related works, and we conclude the paper with 
some research perspectives in Section 6. 

2 Event-B 

2.1 General presentation 

Event-B was introduced by J.-R. Abrial [?,?]. It is a formal development method 
as well as a specification language. In event-B, components are composed of con- 
stant declarations (sets, constants, properties), state specification (vari- 
ables, invariant), initialisation and set of events. The events are defined by 
e = eBody where e is the name of the event and eBody is a guarded generalized 
substitution [?]. The events do not take parameters and do not return result 
values. They do not get preconditions and do terminate. Their effect is only to 
modify the internal state. If S is a component, then we denote by Interface(S) 
the set of its events. 

A well-typed and well-defined component is consistent if initialization Init 
establishes the invariant of the component and if each event preserves the invari- 
ant. So, using the notation [S]R as the weakest precondition of R for substitution 
S, the consistency of a component is expressed by the proof obligations: [Init]I 
and / => [eBody]I for each event. 

In the paper, we use the notions of before-after predicate of substitution 
T for variables x (prd 2 ,(r)) and the feasability predicate of a substitution as 
defined in the B-Book: fis(T) ^ -^[T}false [?]. Finally, the notation (T)R means 
-i[T]-ii?, that is to say, there exists a computation of T which terminates in a 
state verifying R. 



1 http://www.trustcd-logic.fr/ 



2.2 Events and traces 



The events have the form "e = G => T" where G is a predicate, T is a 
generalized substitution such that I A G => fis(T). Predicate G is called the 
guard of e and T is its action. They are respectively denoted by Guard(e) and 
Action{e). If the syntactic definition of an event e = S does not fulfill this 
form, it can be built by computing e = fis(5) => S. Following the so-called 
event-based approach [?], the semantics of event-B systems can be chosen to be 
the set of all the valid sequences of event executions. 

Definition 1 (Traces of Event-B systems) A finite sequence of event occur- 
rences eo.e1.e2 . . . e n is a trace of system S if and only if eo is the initialisation 
of S, {ei, e2, ■ • ■ , e„} C Interface(S) and fis(eo ; e\ ; e2 ; ... ; e„) ^ true. 

The set of all the finite traces of a system S is called Traces (S). For the initial- 
isation, one can notice that prd x (imf) does not depend on the initial values of 
the variables and that Guard(Init) <^> true. The following property characterizes 
traces by the existence of intermediary states Xi in which the guard of a holds 
and where the pair (xi, Xi + \) is in the before-after predicate of event e^: 

Property 1 (Trace characterization) Let x be the variable space of system 

S, then: eo.ei e„ <E Traces(S) 

3xo,...,x n+ i • ALo([ x : = Xi]Guard(ei) A [x,x' := Xi,x i+1 }prd x (Action(ei))) 

2.3 Event-B refinement 

In the event-B method, a refinement is a component called refinement. The 
variables can be refined (i.e. made more concrete) and a gluing invariant de- 
scribes the relationship between the variables of the refinement and those of the 
abstraction. The events of refinement TZ must at least contain those of the ab- 
straction S (i.e. Interface(S) C Interface(lZ)). The other events are called new 
events. 

We recall here the proof obligations of system refinements. Let / be the invari- 
ant of the abstraction S and J be the invariant of refinement TZ, then the gluing 
invariant is the conjunction I A J. The refinement is performed elementwise, that 
is to say, the abstract initialisation is refined by the concrete initialisation and 
each abstract event is refined by its concrete counterpart. Proof obligations that 
establish the consistency of refinements are : 

For initialisation Init : [Init R ](Init s )J 
For events e of Interface^) : I A J => [e R ](e s )J 
For the new events ne R : I A J => [ne R ](sk\p)J 

New events cannot indefinitely take the control, i.e. the refined system cannot 
diverge more often that the abstract one. So, a variant V is declared in the refined 
system, as an expression on a well-founded set (usually the natural numbers), 
and the new events must satisfy (v is a fresh variable) : 



V is a natural expression : I A J => V G N 

New events ne R decrease the variant : J A J => [u := V][ne fl ](y < w) 

Finally, a proof obligation of liveness preservation is usually required. If S con- 
tains to events and 1Z contains p new events, then: 

IAJ^> (V™ ! GW(ef ) => (V™ ! GW(ef ) V VLi Guanine?))) 

Traces associated to refinements are defined as for the systems. 

3 Symbolic labelled transition systems associated to B 
systems 

3.1 Symbolic transition systems 

We define symbolic labelled transition systems: 

Definition 2 (Symbolic labelled transition system) A symbolic labelled tran- 
sition system (SLTS) is a J^-uple (N, Init, U, W) where 

- N is a set of states, and Init is the initial state (Init G N) 

- U is a set of labels of the form (D, A, e), where D and A are predicates and 

e is an event name 

- W is a transition relation W C F(N x U x N). 

A transition (E, (D, A, e), F) means that, in state E, the event e is enabled 
if D holds and, starting from state E, if event e is enabled, then it reaches state 
F if A holds. Predicate D is called the enabledness predicate and A is called the 
reachability predicate. 

States N are interpreted as subsets of variable spaces on variables x. So, the 
interpretation of N is given by a function X such that 1(E) is a predicate on free 
variables x which characterizes the subset represented by E. In the next defini- 
tion, we determine the actual conditions to cross a transition from a particular 
state value x\ of E\ to xi of E% by an event e which is defined in an event- B 
system S. For that, e must be enabled in x\, X2 must be reachable from x\ by 
e, and (x\,x<i) must belong to the before-after predicate of e: 

Definition 3 (Transition crossing) Let (Ei, (D, A, e), E2) be a transition of 
a SLTS T on a system S, and given x\ and X2 some values of the state variables 
x which satisfy the invariant of S , then a crossing from x\ to X2 by this transition 
is legal if and only if : 1. [x := xi]{I(E\) ADAi) 

2. [x,x' :— xi,x 2 ] prd x (Action(e)) 

3. [x := X2]1(E 2 ) 
Such a legal transition crossing is denoted by : 

(Ei,xi) ~*( D ' A ' e U (£2,2:2) 

Now, we introduce the notion of path in a symbolic labelled transition system. 
A path is a sequence of event occurrences, starting from the initial state, which 
goes over a transition system through legal transition crossings. 



Definition 4 (Paths) Given a symbolic labelled transition system T on a sys- 
tem S, a sequence of event occurrences cq e n +i is a path in T if there exists 

a list of states E , ■ ■ ■ ,E n+ \ of N , with E n = Init-r, and a list of transitions 
(Di,Ai,ei),i G 0..n, such that : 

3x , • ■ • , x n +i ■ {N!= Q {{Ei,Xi) (E i+1 ,x i+1 ))) 

The set of all the finite paths of T is called Paths (T). 
3.2 Construction of states and transitions 

The aim of this section is to show how to compute a SLTS, from an event- B 
system S and given a set of states N. First, to build the states N, consider a 
list of predicates {Pi, . . . , P„} on the variable space. We require that this set is 
complete with respect to the invariant, i.e. all the states specified by the invariant 
are included in the states determined by the Pi predicates, i.e. 

n 

i => V 'Pi 

i=l 

Then, the states of the SLTS are N = {Inits, E\, . . . , E n } with the interpretation 
defined by: 

1 (Inits) = true 1(Ei) = Pi A I, i G l..n 

We denote by Nl the set — {Inits}- From the completeness property above 
and the definition of N, we get: I <^> \J™ =l I(Ei). 

Now, we express the conditions to ensure that a symbolic labelled transition 
system T represents the same set of behaviors as the associated system S. For 
that, in a starting state E, the cnabledness condition must be equivalent to the 
guard of the event e, and if the target state is F, the reachability condition must 
be equivalent to the possibility to reach F through e, when the enabledness 
predicate holds, so the condition: 

Condition 1 (Valid transitions) Let S be a system, E and F two states in 
N as defined above, and e an event, then the transition (E,(D,A,e),F) is valid if 
and only if predicates D and A satisfy : 

a) 1(E) (D & Guard(e)) 

b) 1(E) A Guard(e) => (A & (Action(e))l(F)) 

Notice that, by applying the definition of the conjugate weakest precondition, 
condition b) is equivalent to : 

1(E) A Guard(e) => (A ^> 3x' ■ (prd x (Action(e)) A [x := x']l(F))) 

A SLTS with all the transitions valid with respect to a system S is called a valid 
symbolic labelled transition system. 



Theorem 1 (Traces and paths equality) Let S be an event-B system with 
invariant I and events Ev and let T be a valid symbolic labelled transition system 
built from S, then: 

Traces (S) = Paths (T) 

Proof: We prove that, for all t, t 6 Paths(T) & t e Traces(S). 

The path t = eo-ei e„ is a path for the state sequence Eq, E\, ... , E n+ \ iff 

(Definition 4): 3x , . . . , x n+1 ■ A? =0 ((^i. *i) -> (D - A *^ ) - (£7 i+ i,x i+ i)) 
By using Definition 3, we get: 

3x , . . . ,a; n+ i • A"=o([ x := AAA Aj) 

A [a;, a;' := Xi,x i+1 }prd x (Action(ei)) A [a; := a; i+ i]X(.E; + i)) 
By Condition 1, one can replace Dj by Guard(ei) and Ai by 3x'-(prd 2 .(^4ctton(e»))A 
[a; := x']I(Ei + i)). The formula above is simplified and becomes: 

(1) 3x , . . . ,x n+ i ■ /\" =0 {[x := Xi]{l{Ei) A Guard{ei)) 

A [x, x' := Xi, Xi+ijprd^, (Action (e^)) A [a; := £j + i]X(.Ei + i)) 
We must prove that this formula is equivalent to the characterization of the 
traces (Property 1): 

(2) 3x , . . .,x n+1 ■ /\™ =0 ([x := Xi\Guard(ei) 

A [x, x' :— Xi, x i+ i]prd x (Action(ei)) A [x := Xi + \]I) 
Implication (1) =>■ (2) is verified because states Ei are such that I(Ei) => I (Sec- 
tion 3.2). To prove (2) => (1), we must exhibit a list of states E , E\, ... , E n+ \ 
such that these states satisfy (1). This follows from the fact that 1(Eq) = true 
and from / => V"=i ^-(-^i)> which ensures that one of the states I(Ei) necessarily 
holds when / hold. □ 



3.3 Labelled transition systems for the refinements 

We propose now the construction of a symbolic labelled transition system for 
the refinements. Our aim is to highlight the links between abstract and concrete 
transition systems, while preserving the overall structure of the abstract system. 
One aspect of the refinement is the change of the variable representation and 
redefinition of the events of the abstraction, according to the new representation. 
The point is taken into account by the notion of state projection. 

In the following, S is a specification, 1Z is its refinement with gluing invariant 
L, and T s is a symbolic labelled transition system for S. States E s and F s are 
states in T s ■ We assume that the variable set x s of S is disjoint to the variable 
set x R of the refinement. If some variables of the specification are kept in the 
refinement, they can be renamed and an equality between both variables is added 
to the invariant. 

Definition 5 (State projection) Let S be a system with variables x s and 1Z 
be the refinement of S according to L. A state E R of , E R ^ Init-jz is the 
projection of E s of T s , denoted by E R = Proj L (E s ), iff: 

1(E R ) & 3x s ■ (L A 1{E S )) 



We propose to build a SLTS, called Proj L (T S ), in which states are automat- 
ically deduced from abstract states and gluing invariant. The SLTS projection 
Proj L (T S ) of the refinement TZ of system S with gluing invariant L is such that: 
the initial state is any q with X(q ) = true; the other states of the projection 
are the projections of abstract states, i.e. iVl^ = {Proj L (q) \ q G 7V1 S }. The 
transitions are (E R , (D' , A', e R ), F R ) where e R G TZ and D 1 , A' are such that 
Condition 1 is satisfied. A transition (E R , (D' , A' , e R ), F R ) is said a projection of 
transition (E s , (D, A, e s ),F s ) iff E R = Proj L (E s ), F R = Proj L (F S ) and event 
e R is the refinement of e s . By construction, Paths{Proj L (T S )) = TracesiJZ). 
This equality can be proved in the same way as in Theorem f . 

Property 2 (Transition projection) With the definitions above, 

let (E R , (D',A',e R ),F R ) be the projection of transition (E s , (D, A, e s ),F s ), 

then we have: 

1(E S ) A L A D'^D 

This property says that any transition enabled from a state Proj L (E S ) in a 
refinement TZ actually must be enabled in specification S (if the refinement is 
proved correct). Property 2 can make the computation of the transitions sim- 
pler. Indeed, if e G Interface(S), then, for all the transitions (E s ,e,F s ) of the 
abstraction, it is only necessary to examine the transitions (Proj L (E s ) 7 e,E') 
with E 1 G N1 R . No other transition can be labelled by e from this state. 

Another key aspect of refinement is the refinement of behaviors. New events 
may be introduced that make the actions more detailed. These new events are 
not observable at the abstract level, as the stuttering in TLA [?]. Very often, 
new variables are introduced. Thus, it is useful to visualize the states referring 
to these variable changes. In order to preserve the structure of the abstract 
system, we choose to refine each abstract state in an independent way. So, the 
transitions, relative to events which belong to Interface(S) , are preserved by the 
introduction of hierarchical states. 

Definition 6 (Hierarchical states) A set of sub-states {E R , . . . , E R } can be 

associated to a super-state Proj L (E S ) of TZ if and only if 

m 

\/l(E R )^l(Proj L (E s )) 
i=i 

In a refined system, the user must decide what projections of abstract states 
are decomposed and s/he must provide the predicates of the decomposition. 
If the abstract states are disjoint, then the transitions associated to the new 
events appear only between the sub-states of a hierarchical state. An example 
of refinement with decomposition of states is given in Section 4.4. 

4 The GeneSyst tool 
4.1 Presentation 

The GeneSyst tool is intended to generate a symbolic labelled transition system 
T from an event-B system S and a set of states N. Such a generated SLTS 



will be denoted by T(S,N). The input of the tool is a B component, where 
the assertions clause contains the formula Pi V ... V P„, which characterizes 
the list of predicates {Pi, . . . , P„}. By this way, the condition of completeness 
(section 3.2) is generated as proof obligation. 

We give a sketch of the algorithm which computes the transitions of T(S, N) : 
it uses three main variables: the set of visited states, visited, the set of processed 
states, processed, and the set of computed transitions tr. First, the initial state 
is put in the visited set. Then each state E in the visited set is processed: this 
consists in computing the transitions (E, (D, A, e), F) with all events e to all 
non-initial states F of the system. Predicates D and A are determined following 
the algorithm defined in the following section. If D or A are not false then the 
transition (E, (D,A,e),F) is added to tr, and if F has not been processed, it 
is put in the visited set. After the processing of state E, E is removed from 
visited and put in set processed. When visited is empty, then tr contains all 
the computed transitions of T(S, N) and processed contains the set of reachable 
states. The algorithm terminates, because the set of states to be visited is finite 
(bounded by the cardinal of N). This algorithm guarantees that the resulting 
SLTS is a valid transition system for S, with given states N. 

4.2 Proof obligations 

A subprocedure of the algorithm is to determine effectively the enabledness 
predicate and the reachability predicate, given a triple (E,e,F). For sake of 
usability of the resulting transition system, it is interesting to examine three 
cases: predicates are true, false or other. This information can be obtained by 
proof obligations. In Fig. 1, we give the conditions for the calculus of these 
predicates. Obviously, if D and/or A is false, then the transition is not possible. 





Proof obligations 


D for (E, e, F) 


(1) 

(2) 
(3) 


Vx • (1(E) Guard (e)) 
Va; ■ (1(E) -, Guard (ej) 
3x ■ (1(E) A Guard (e)) 


true 
false 
Guard(e) 




Proof obligations 


A for (E, e, F) 


(4) 
(5) 
(6) 


Vx • (1(E) A Guard(e) => (Action(e))l(F)) 
Va; ■ (1(E) A Guard(e) [Action (e)]-. 1(F)) 
3x ■ (1(E) A Guard(e) A (Action(e))l(F)) 


true 
false 
(Action(e))l(F) 



Fig. 1. Proof obligations for enabledness and reachability 



In practice, the GeneSyst tool computes the proof obligations (POs) above 
and interacts with AtelierB to discharge the POs. For each triple (E, e, F): 

1. if proof obligation (1) is automatically discharged then D is true. 

2. if proof obligation (2) is automatically discharged then D is false and tran- 
sition (E,e,F) does not occur in the resulting T(S,N). 

3. otherwise, D is Guard(e) by default. 



Then, after cases 1. and 3., GeneSyst computes the proof obligations for deter- 
mining the reachability predicate A. 

4. if proof obligation (4) is automatically discharged then A is true. 

5. if proof obligation (5) is automatically discharged then A is false and tran- 
sition (E,e,F) does not occur in the resulting T(S,N). 

6. otherwise, the transition is kept with (Action(e)) 1(F) as A, by default. 

We can notice that Condition 1 about the validity of the transitions is well 
satisfied by construction. The by default cases in 3. and 6. correspond to several 
possibilities. Either there exist values in state E for which the transition is cross- 
able (guard of e is true and state F is reachable), or there are not (the guard 
is false or state F is not reachable). However, in both possibilities, these tran- 
sitions are included in the resulting transition system. To manage this feature, 
we define the notion of minimal symbolic labelled transition system. 

Definition 7 (Minimal SLTS) A minimal SLTS is a SLTS where all the tran- 
sitions are valid, i.e. satisfy a) and b) of Condition 1, and also satisfy: 
c) D false and A false 

A SLTS built by GeneSyst is minimal if all the proof obligations of D and A 
have been effectively discharged in step 1. or 2. and step 4. or 5. in the algorithm 
above. To minimize the number of by-default transitionss, we have designed two 
variants of the algorithm. The first optional alternative of the algorithm is to 
change cases 3. and 6. into: 

3'. if proof obligation (3) is automatically discharged, then D is Guard(e) by 

proof, otherwise, D is Guard(e) by default. 
6'. if proof obligation (6) is automatically discharged, then A is (Action(e)) 1(F) 

by proof, otherwise, the transition is kept with (Action(e))I(F) as A by 

default. 

Another option of the tool allows the user to get the POs which have not been 
automatically discharged. Then, s/he can do an interactive proof to complete 
the work and return the information that the PO is discharged or not. However, 
the interactive mode is not very practicable when there are a great number of 
proof obligations that are not automatically discharged. It becomes useful to 
check actually the absence of some critical transitions (cases 2. and 4.). 

4.3 Transition systems associated to the Demoney case study 

In Fig. 2, we give an example of transition system generated from a subset of 
the abstract specification of the Demoney case study. The B machine is pro- 
vided in appendix. We just have represented four methods imposed by the De- 
money specification [?]: InitializeTransaction, CompleteTransaction, Reset and 
GetData. The two methods InitializeTransaction and CompleteTransaction have 



to be executed in sequence. If they are called in the wrong order then an er- 
ror must be returned. Moreover, any other methods cannot be invoked between 
them, except the method Reset which models the extraction of the card from 
the terminal. If it is called during a transaction, all the internal variables must 
be restored at their initial values. Finally, method GetData has been defined to 
represent any other method which plays a neutral role with respect to transac- 
tions. 

Let us notice that our model has been expressed with events. In the applet De- 
money, methods have neither parameters nor result, because they communicate 
through a global variable, named APDU, which allows the information transfert 
between the card and the terminal. An error can be returned by means of the 
same variable. Finally, methods have no precondition, because they are callable 
at any time. So the transformation of methods in events is straightforward. 

In the diagrams generated by GeneSyst, transitions are prefixed by the infor- 
mation about predicates D and A. A predicate denoted by "[ ]" means true, while 
"[G]" means that the transition is computed by cases 3. or 6. (see section 4.2). 



[ J [ J InitializeTransaction 
[ J [ J CompleteTransaction 



[ J [GJ GetData 
[ ] [ ] InitializeTransaction 
[ J [GJ CompleteTransaction 



L J I J Reset 
[ J I J GetData 
[III InitializeTransaction 




[ ] [ ] Reset 
[ J [GJ GetData 
[ ] [GJ InitializeTransaction 
[ J [GJ CompleteTransaction 



Fig. 2. Transition system associated to the error detection in the Demoney specification 



Fig. 2 points out cases in which errors can occur. Transitions have no enabled- 
ness condition, because all the guards are true in the model. Some reachability 
conditions do not reduce to true, as for the event GetData, which is defined by: 

GetData = if EngagedTrans = TRUE then 

Error := TRUE || EngagedTrans := FALSE 
else Error := FALSE end; 

From state Error = FALSE, event GetData can reach the state Error = TRUE with 
the condition EngagedTrans — TRUE and stays in Error = FALSE otherwise. Let us 
remark also that GetData is enabled in state Error = TRUE and always reaches 
state Error = FALSE because of the invariant Error = TRUE => EngagedTrans = 
FALSE. 



4.4 Transition system associated to a refinement of Demoney 

In our refinement of Demoney, the boolean variable Error is changed into a value 
of a given set StatusType, which intends to describe error codes, as imposed by 



the specification [?]. In the same way, the boolean variable EngagedTrans is 
refined into a value of a given set TransactionType , which indicates the exact 
type of the current transaction. Finally, we have introduced the channel with 
two levels of security (FALSE and TRUE). All this information is declared in the 
invariant below (see also the refinement in appendix): 



INVARIANT 

StatusWord £ StatusType A CurTransaction £ TransactionType A 
ChannellsSecured £ BOOL A 

((Error = FALSE) (StatusWord = ISOJDk)) A 
((EngagedTrans = FALSE) <4> (CurTransaction = None)) A 
((CurTransaction ^ None) =>• (ChannellsSecured — TRUE)) A 
((StatusWord / ISOJDk) => (CurTransaction = None)) 



Fig. 3 is built from this refinement. State Error = FALSE, which corresponds 
to StatusWord = ISOJDk, is split into two states according to that a transaction 
is engaged or not. 
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Fig. 3. Transition system associated to the refinement of the error detection 



As expressed in Definition 6, the predicate given to GeneSyst to describe the 
states has to be a conjonction of equivalences between an abstract state and a 
disjonction of refined states. This predicate is written in the assertion clause. 
For example, the assertion below has been used to generate Fig. 3. 

((Error = TRUE) <4> ((StatusWord ^ ISOJDk A CurTransaction = None) 

V (StatusWord ± ISO .Ok A CurTransaction =fi None))) 

A 

((Error = FALSE) ((StatusWord = ISOJDk A CurTransaction = None) 

V (StatusWord = ISOJDk A CurTransaction None))) 

With the splitting of the state Error = FALSE, transition conditions are 
simplified in true or false or, in the worst case, are unchanged. For example, 
in Fig. 2, the transition labelled by [][G]CompleteTransaction and going from 



Error = FALSE to Error = TRUE is, in Fig. 3, going from StatusWord = ISO.OkA 
CurTransaction = None to Status Word 7^ ISOJDk A CurTransaction — None with 
the label [}[}CompleteTransaction. So, its reachability has been made more pre- 
cise. The same effect occurs on transition [][G]CompleteTransaction going from 
Error = FALSE to Error = FALSE, which is refined by [][]CompleteTransaction 
going from CurTransaction / None to CurTransaction = None in the super-state 
Error = FALSE. These two specializations are directly due to the introduction of 
the CurTransaction variable. 

5 Verification of Security Properties on Demoney 

In this section we propose a formalism to express properties relative to security 
aspects and we show how GeneSyst can be used to verify these properties. We 
will next give a concrete example relative to the Demoney case study. 

5.1 Properties 

Generally, security is designed and implemented through different levels of ab- 
straction. Security policies are defined by a set of rules according to which the 
system can be regulated, in order to guarantee expected properties, as confi- 
dentiality or integrity. Security policies are then implemented through software 
and hardware functions, called security mechanisms. Such an approach has been 
adopted by the Common Criteria norm [?] which proposes, through the notion 
of assurance requirements, a catalogue of security policies and a hierarchy of 
mechanisms. 

In this paper we focus on security properties relative to constraints on the 
global behavior of the system, as authentication procedures or access control. In 
this case, security requirements can be seen as constraints on the execution order 
of atomic actions, as operation calls. F. Schneider claims in [?] that automata 
are a well-adapted formalism which can, both, be used to specify some forms 
of security policies and to control implementations during their execution. On 
the other hand, K. Trcntclman and M. Huisman [?] propose a logic that can be 
used also to express some forms of security properties, as temporal properties 
on JML specifications. 

We adopt a formalism based on logic formulas, which allows us to point 
out expected behaviors either in specifying correct executions, or in specifying 
security violations. That offers a good flexibility and is suitable to describe as well 
open policies as closed policies, respectively relative to negative authorizations 
and positive authorizations [?]. 

5.2 Predicates of security properties 

Security properties are often represented as a list of first order logic formulas that 
have to be verified. We want to define some predicates to make the expression 
of these formulas easier. Predicates that we introduce express the ability of an 



event to start from a state (Enabled and AlwaysEnabled) and the existence of a 
transition between two states (Crossable and AlwaysCrossable). 

Definition 8 (Enabled, AlwaysEnabled, Crossable and AlwaysCrossable) 
Given p\ and p 2 two state predicates and an event ev from a system S with 
variables x, then: 

Enabled (pi,ev) = 3x ■ (pi A Guard(ev)) 

AlwaysEnabled(p\,ev) = Vx • (pi => Guard (ev)) 

Crossable(p\,ev,p 2 ) = 3x ■ (pi A (ev)p2) 

AlwaysCrossable(pi,ev,p 2 ) = Vx • (pi => [ev]p 2 ) 

Let us note that if Enabled (pi,ev) O false, then, for each predicate p 2 , 
AlwaysCrossable(p\,ev,p 2 ) will be true instead oi false, which is the intuitive 
value expected. In the same way, if p\ is equivalent to false then AlwaysEnabled 
and AlwaysCrossable are always true. Moreover, we can notice that: 

Crossable(p\,ev,p 2 ) => Enabled (pi, ev) 
From this definition we can deduce the properties below, relative to the impli- 
cation: 

Property 3 Given pi, p 2 and pz three predicates and an event ev then: 

— if p\ => ps and Enabled (pi,ev) then Enabled (p 3 ,ev) 

~ if P3 =^ Pi and Always Enabled (p i, ev) then AlwaysEnabled(p^, ev) 

— if pi => P3 and Crossable (p\, ev,p 2 ) then Crossable(p^,ev,p 2 ) 

— if Vi P3 an d Crossable(p\,ev,p 2 ) then Crossable(pi,ev,p 3 ) 

~ if P3 =^ Pi and AlwaysCrossable(pi, ev,p 2 ) then AlwaysCrossable(ps, ev,p 2 ) 

— if P2 => P3 and AlwaysCrossable(pi,ev,p 2 ) then AlwaysCrossable(pi,ev,ps) 

Here are two examples: 

Reactivity of a system. The JavaCard specification imposes that any APDU 
instruction is callable at any time. Given S a system and / its invariant, then 
this formula can be expressed as follows: 

Veu • (ev G Interface(S) => AlwaysEnabled (I , ev)) 

Unicity of the ways to reach a state. In some cases, like access control, we 
want to impose that the only way to reach a state P is to execute a particular 
event Begin. If I is the invariant of S, then this property can be expressed as 
follows: 

Mev ■ (ev e Interface(S) A ev ^ Begin => AlwaysCrossable(I , ev, -*P)) 
5.3 Property checking using GeneSyst SLTS 

Security properties could be verified on B specifications, using definition 8. Nev- 
ertheless, in some cases, the SLTS produced by GeneSyst can be directly ex- 
ploited. Then, the verification consists in using syntactic information relative to 
enabledness and reachability of transitions. Properties 4-7 list the different cases 
where the predicates above can be directly established from a symbolic labelled 
transition system. 



Properties 4-7 share the following hypothesis: Given an event e and q\, q 2 
two states from a SLTS T , such as I{qi) & false and (qi, (D, A, e), q 2 ) € Wt, 
then predicates Enabled, AlwaysEnabled , Crossable and Always Cms sable can be 
determined as follows:. 



Property 4 (Enabledness condition - general case) 

1. D = true => Enabled (qi, e) 

2. D = false => -1 Enabled (qi,e) 

3. D = true => AlwaysEnabled(qi,e) 
4- D = false => —1 AlwaysEnabled (qi, e) 

If the SLTS used to verify the property is minimal, then Property 4 can be 
enlarged: the conditions are necessary (and sufficient) and conditions 1 and 4 
are refined. 



Property 5 (Enabledness for minimal SLTS) 

1. D ^ false Enabled(q\,e) 

2. D = false -1 Enabled (qi,e) 

3. D = true AlwaysEnabled(qi,e) 
4- true ^AlwaysEnabled(qi,e) 

In the same way, syntactic conditions to check Crossable and AlwaysCrossable 
predicates are: 

Property 6 (Reachability condition - general case) 

5. A = true => Crossable(qi 1 e 1 q 2 ) 

6. A = false V D = false => ^Crossable(qi,e,q 2 ) 

7. A = true A 

V<7i • (<Z2 # qi => (51, (D, A 2 , e), qi) g Wt) => Alw <ay <s Cross able (qi,e, q 2 ) 

8. A = false => ^AlwaysCrossable(qi,e 7 q 2 ) 

Cases 7 and 8 are not symetric, as it would be expected, because, syntacticaly, 
we can just compare names of states, not the intersection of their interpretation. 
Just as for enabledness, the conditions can be enlarged, when the SLTS is min- 
imal, as follow: 

Property 7 (Reachability for minimal SLTS) 

5. A^ false <^> Crossable(qi 1 e 1 q 2 ) 

6. A = false V D = false <^> ^Crossable(qi,e,q 2 ) 

8. A ^ true => -^AlwaysCrossable(q\ 1 e 1 q 2 ) 

Cases 7 and 8 are just sufficient conditions because of the limitation of the 
syntactic verification. Case 7 is not present in Property 7 because it is the same 
as in Property 6 Finally, Property 3 allows the deduction of derived properties 
from the four properties above, by weakening or strenghtening the states. 



5.4 Example of a property checking 

In this section, we develop a real example of Demoney property and we do its 
verification by using the SLTS given in Figure 3. In the Demoney specification [?], 
the two APDU instructions InitializeTransaction and CompleteTransaction have 
to be executed in sequence, without any other instructions between them and 
without reaching any error state, to make a transaction. However, the card can 
be withdrawn at any time (modelled by the Reset event) without generating any 
error. Transaction atomicity property can be decomposed in five formulas given 
below, where / stands for the invariant of the Demoney specification. Moreover, 
SLTS of Figure 3 is minimal and events are always enabled from all state of the 
SLTS. Finally, note than the invariant I is equivalent to the union of all state 
predicates (Section 3.2). 

Formula 1: There exists at least a value in / such that the event Initialize- 
Transaction can reach CurTransaction ^ None: 

Crossable{I , InitializeTransaction, CurTransaction ^ None) 
Predicate CurTransaction ^ None directly corresponds to a state predicate. 
Since there exists a transition from CurTransaction = None A StatusWord = 
ISO-Ok to CurTransaction ^ None, labelled with [ ]{G}InitializeTransaction, 
then we can use case 5 of Property 7 and conclude that the Formula 1 is true. 

Formula 2: For all values, the event InitializeTransaction goes into the state 
CurTransaction ^ None or into an error state: 

AlwaysCrossable (I, InitializeTransaction, 

CurTransaction ^ None V StatusWord =/= I SO -Ok) 
CurTransaction ^ None and StatusWord ^ ISO-Ok are two state predicates, 
and all the transitions labelled with InitializeTransaction go only in one of these 
states. Then, due to case 7 of property 6, this formula is true. 

Formula 3: From CurTransaction^N one, all events, but CompleteTransaction 
and Reset, go to an error state: 

Ve • (e G Interface(S) A e / CompleteTransaction A e ^ Reset => 
AlwaysCrossable(CurTransaction ^ None, e, StatusWord ^ ISO-Ok) 
The two predicates correspond to state predicates and the only events which 
go elsewhere than StatusWord ^ ISOJJk from CurTransaction ^ None are 
CompleteTransaction and Reset. Thus Formula 4 is true (case 7 of Property 6). 

Formula 4: Except InitializeTransaction, no event can reach CurTransaction 
^ None: 

Ve • (e G Interface(S) A e / InitializeTransaction => 
Alw ays Cross able (1 , e, CurTransaction = None)) 
Predicate CurTransaction = None is the union of two existing state predicates. 
So, we have to check if there exists an event, different from InitializeTransaction, 
that can reach CurTransaction ^ None. Since it is not the case, this formula is 
true (case 7 of Property 6). 



Formula 5: No transition labelled by CompleteTrans action or Reset is reflexive 
on state Cur Trans action ^ None: 

-^Crossable(CurTransaction ^ None,CompleteTransaction, 
CurTransaction ^ None) 

and -^Crossable{CurTransaction ^ None, Reset, CurTransaction ^ None) 
CurTransaction ^ None corresponds to a state predicate and no Complete- 
Transaction or Reset reflexive transition occurs. Thus this formula is true (case 5 
of Property 7). 

The model of Demoney is thus correct relatively to the atomicity security 
property of transactions. However, during the realisation of this example, which 
is a simplified Demoney applet, we found three errors due to an erroneous sim- 
plification of our complete model of Demoney. 

The originality of this approach is to have brought back, under some hypothe- 
ses, the verification of security properties to a syntactic checking. However, it 
is important to be careful about the real value of the crossing conditions gen- 
erated by GeneSyst. Indeed, if some proof obligations are not (automatically) 
discharged, the transitions system will have by-default transitions. Then, to 
properly exploit the information, we have to be sure that the property to be 
verify can be checked on a non- minimal SLTS. 

6 Related works and Conclusion 

The work presented here is in line with the ideas presented in [?] , itself inspired 
by [?]. In [?], the authors propose the construction of a labelled transition sys- 
tem which is a finite state abstraction of the behavior of an event- B system. 
The existence of transitions is determined by proof obligations, as here, but 
the resulting transition system does not contain any information about transi- 
tion crossing. Moreover, the paper does not consider the refinement step in the 
diagram representation. 

Other work is devoted to the translation of dynamic aspects described by 
statecharts in the B formalism (for instance [?,?]). These approaches are inverse 
of ours, because they go from a diagrammatic representation to an encoding in 
a formal text. Their objective is to build a B model from UML descriptions. 
On our side, we suppose that the model has been stated and we are interested 
in representing the precise behavior of the system with respect to (a part of) 
variables, in order to check properties, or to validate the model against the 
requirements. 

A similar approach has been envisaged for TLA [?] and extended in [?,?] 




to take in account liveness properties and refinement. As in [?], the generated 
diagrams are abstractions of the system behavior. 

Several tools are dedicated to the analysis of the behavior of B components by 
the way of the animation of machines [?] or by local exhaustive model checking 
[?]. Even if some of them allow the generation of symbolic traces, these tools can 




be considered as "testing" tools. They provide particular execution sequences of 
the system, not a static representation of all the behaviors. In [?], the authors 
describe the generation of statecharts from event-B systems, but their approach 
suffers from several restrictions and their diagrams are not symbolic. 

In this paper, we have presented the GeneSyst tool, its logical foundations 
and its application to the verification of security properties. In the first part, 
we introduced the definition of traces of event-B systems and refinements. We 
formalized the notion of symbolic labelled transition systems, with transitions 
decorated by enabledness and reachability predicates. This gives a complete and 
precise view of the behavior of the system, which can be exploited for various 
objectives. 

We described the algorithm that is implemented to generate a SLTS from a 
B system and a set of states, characterized by predicates. The computation of 
effective transitions between states is performed by proving proof obligations. 
Due to the indecidability of the proof process, we have the choice between two 
kinds of (non exclusive) results: the generation is automatic, but we can get 
more transitions than in the real system, or the user completes interactively 
the non-conclusive proofs and then, the resulting automaton reflects exactly the 
behavior of the system. 

The user can take profit of the freedom degree achieved by the choice of the 
states, to obtain the best analyses useful for him/her purpose. Non classical ver- 
ification techniques can be designed and implemented at this stage, to assess or 
to validate the model, as it was shown in the last part of the paper. This opens 
a large field of research in the domains of security properties, confidentiality, 
access control, validation of models with respect to the requirements, automatic 
documentation of specifications, etc. Our present research work is to develop 
a set of techniques in the GECCOO 2 project to express and to check security 
properties, as it was sketched in the paper. We want to investigate the extrac- 
tion of states from the specification of property automata, the use of refinement 
to split states and achieve a suitable level of decomposition in order to check a 
property. Another work is to deal with complex B models (several refinement 
chains together with composition clauses sees, includes, etc.), either by com- 
posing partial labelled transition systems, or by flattening a structured model 
before computing the whole associated SLTS. 



2 "Generation de Code Certifie Oriente Objet". Project of Program "ACI Securite 
Informatique" , 2003. 



Appendix 

Machine of the Demoney specification (diagram in Fig. 2, Section 4.3): 
machine Demoney 

VARIABLES 

Error, EngagedTrans 

INVARIANT 

Error G BOOL A EngagedTrans e BOOL A 
(Error = TRUE => EngagedTrans = FALSE) A 
(EngagedTrans = TRUE .Error = FALSE) 

ASSERTIONS 

/* The assertion provides the states for tool GeneSyst */ 

/* Here, only two states are considered according to the Error values */ 

Error = FALSE V Error = TRUE 

INITIALISATION 

Error := FALSE || EngagedTrans := FALSE 

OPERATIONS 

Reset = begin EngagedTrans := FALSE || Error := FALSE end; 
GetData = 

if EngagedTrans = TRUE then 

Error := TRUE || EngagedTrans := FALSE 

else Error := FALSE 

END; 

InitializeTransaction = 

if EngagedTrans = TRUE then 

Error := TRUE || EngagedTrans := FALSE 

ELSE 

ANY SW WHERE SW € BOOL THEN 

Error := SW \\ EngagedTrans := boo\(SW = FALSE) 

END 
END; 

CompleteTrans action = 

if EngagedTrans = FALSE then 

Error := TRUE 
else Error := FALSE || EngagedTrans := FALSE 

END 

END 



Refinement of the Demoney specification (diagram in Fig. 3, Section 4.4): 

refinement Demoney _R1 
refines Demoney 

SETS 

Trans actionType = {Credit, Debit, None}; 
StatusType = {ISO.Error,ISO.Ok} 

VARIABLES 

StatusWord , CurTransaction, ChannellsSecured 



INVARIANT 

StatusWord € StatusType A CurTransaction € Trans actionType A 
ChannellsSecured e BOOL A 
((StatusWord = ISO-Ok) O (Error = FALSE)) A 
((EngagedTrans = TRUE) <S> (CurTransaction =fc None)) A 
((CurTransaction 7^ None) => ChannellsSecured — TRUE) A 
((StatasWord / ISO.Ok) (CurTransaction = None)) 

ASSERTIONS 

/* Each abstract state is decomposed in two concrete states */ 
/* One of these states is not reachable */ 
((Error = TRUE) & 

((StatusWord / ISO-Ok A CurTransaction = None) 

V (StatusWord / I SO. Ok A CurTransaction =£ N 'one))) 

A 

((Error = FALSE) « 

((StatusWord = ISO-Ok A CurTransaction — None) 

V (StatusWord = ISO-Ok A CurTransaction / None))) 

INITIALISATION 

Status Word := ISO-Ok \\ ChannellsSecured := FALSE || 
CurTransaction := None 

OPERATIONS 

i?eset = BEGIN 

StatusWord := ISO-Ok \\ ChannellsSecured := FALSE || 
CurTransaction := None 
END; 
GetData — 

if CurTransaction None then 

StatusWord := ISO -Error \\ CurTransaction := None 

ELSE 

Status Word := ISO-Ok 
END; 

InitializeTrans action — 

if CurTransaction / A^one V ChannellsSecured = FALSE then 
StatusWord := ISO-Error \\ CurTransaction := None 

ELSE 

StatusWord :£ StatusType; 

if StatusWord = ISO-Ok then 

CurTransaction :€ {Debit, Credit} 

END 
END; 

CompleteTransaction — 

if CurTransaction = None then 
StatusWord := ISO-Error 

ELSE 

CurTransaction := None j StatusWord := ISO-Ok 

END 

END 



